IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
The Universal Mobile Telecommunications System (UMTS) is a third generation wireless system designed to provide higher data rates and enhanced services to users. The UMTS architecture includes a subsystem known as the IP Multimedia Subsystem (IMS) for supporting traditional telephony as well as new IP multimedia services (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7). IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet. It is expected that IMS will be integrated into current and future Long Term Evolution (LTE) deployments.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. The 3GPP has chosen SIP for signalling between a User Equipment (UE) and the IMS as well as between the components within the IMS.
By way of example, FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be “linked in” during a SIP Session establishment (or indeed for the purpose of any SIP method, session or non-session related). The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's Subscriber Profile.
In the IMS architecture, failure of an S-CSCF has an impact on all users that are currently registered in this S-CSCF. The 3GPP specification “IMS Restoration Procedures on S-CSCF failure” (TS 24.229, TS 29.228 and TS 23.380) is the standard mechanism whereby, at S-CSCF failure, another S-CSCF can take over and restore the registration state of the users. The underlying principle is that, whenever a user registers with the IMS, the S-CSCF allocated to serve that user uploads registration state information (called “Restoration Info”) to the HSS. If the allocated S-CSCF subsequently fails, when the user makes an originating or re-registration request it will be instructed by the IMS network to re-register whereupon the associated I-CSCF will re-select another S-CSCF and this secondary S-CSCF will download the stored Restoration Info from the HSS, restore the state of the user, and start handling the user. In the case where the user registered with the failed S-CSCF is the terminating user for an incoming request, the request will be handled by an alternative S-CSCF. The associated I-CSCF will reselect another S-CSCF and this secondary S-CSCF will download the stored Restoration Info from the HSS, restore the state of the user, and start handling the user.
IMS Restoration Procedures can be used in cases other than S-CSCF failures. For example, consider the case where an operator wants to reduce the load on a certain S-CSCF because of planned maintenance or upgrade to the S-CSCF, or because of problems observed in the S-CSCF (to address an identified problem an operator might want to enable a processor intensive tracing process). To perform these operations, the S-CSCF can trigger a “drain-out” of users from itself, causing these users to be moved to another S-CSCF. This drain out is achieved by triggering the IMS Restoration Procedure in a controlled way.
Within the IMS, situations can occur in which traffic becomes unevenly distributed among the CSCF nodes. This occurs in particular when a node is deliberately taken out of use for maintenance purposes or due to failure. When a CSCF node becomes non-operational or is otherwise unreachable, all IMS traffic is redirected and handled by the remaining operational CSCF nodes. In the case of a failed S-CSCF, the re-allocated, alternative S-CSCF will allocated to the transferred IMS users for the remainder of their registration life cycles (assuming no subsequent failure of the alternative S-CSCF). When the previously non-operational S-CSCF becomes operational again, the traffic distribution among the S-CSCF pool will most likely be unevenly distributed. The S-CSCF re-entering service will have very little traffic compared to the traffic levels of the other S-CSCFs in the pool. Of course, over a period of time, as IMS users de-register and then initiate new initial register procedures, the traffic may become more evenly distributed.
Having an uneven distribution of traffic amongst S-CSCF nodes, even temporarily, is wasteful in terms of IMS network resources. In the absence of an alternative solution, network operators must engineer spare capacity within their networks in anticipation of an uneven traffic distribution.
The IMS Restoration Procedures discussed above is not well suited to the dynamic redistribution of traffic within the IMS as it is intended to deal primarily with S-CSCF failures and the like. Moreover, it results in service problems for affected users, e.g. the dropping of a call involving a user when that user is transferred to another S-CSCF.